@seratch My apologies for the duplicate work.

After looking at both, I think this approach might have a couple of advantages:

• Instead of waiting for the model's full response to finish, this implementation emits the tool_called event the instant the first tool-call chunk arrives in the stream.
• From a maintainability perspective, it also dynamically checks for any tool-call type, so the code won't need to be updated when more tools are added down the line.

This should make the UI feel more responsive, and the code change itself is a bit smaller and more contained. Happy to chat about it or defer to the other solution if that's preferred.

This PR is stale because it has been open for 10 days with no activity.

Hey @seratch @rm-openai.
Merging #974 resolves this problem, but I still see some advantages/improvements in this implementation. Would it be possible to take a look at it, and either go forward with it or close it.

While I am confident #974 works well, I am not sure if your code here works without any issues. Would it be possible to enhance the current code with #974 to produce "tool_called" events as you intend here?

It doesnt. There are merge conflicts that were caused by merging #974. I'll fix them briefly.

@seratch
Rebased onto latest main and resolved conflicts. Happy to proceed with this, or close if you prefer sticking with #974 alone.

As previously mentioned, advantages to this implementation are:

• Instead of waiting for the model's full response to finish, this implementation emits the tool_called event the instant the first tool-call chunk arrives in the stream.
• From a maintainability perspective, it also dynamically checks for any tool-call type, so the code won't need to be updated when more tools are added down the line.